CI went crazy, eh

It looks the ci failure is unrelated to the change.

@jrmuizel this looks great, but I'm not sure about adding it to objc right now. I don't completely understand the relationship between libobjc and reference counting. These functions aren't defined in the public headers for libobjc. The gnustep- implementation of libobjc therefore doesn't include them, but instead implements them as part of Foundation. I think the objc crate's gnustep support might be broken currently, but it's supposed to be supported to some extent 😛

Although Apple's libobjc bakes in some parts of Foundation (like the implementation of NSObject and this), for now I've kept reference-counting stuff out of the objc crate (though it used to be here and #24 was filed when it was removed).

I'm not sure where the best home for this is then. If y'all would be interested in adding this to objc_id, I'd be happy to accept it there! If that's no good for you, maybe in the foundation module of the cocoa crate to replace its NSAutoreleasePool?

Let me know what you think!

These functions aren't defined in the public headers for libobjc.

IIRC, the functions are part of the interface between the compiler and the runtime. They're not normally called from user code, hence not exposed in the normal runtime headers.

The gnustep implementation of libobjc therefore doesn't include them, but instead implements them as part of Foundation.

There might be a compatibiltiy shim for the legacy gcc runtime in Gnustep's Foundation library, but the modern runtime definitely implements them directly.

There might be a compatibiltiy shim for the legacy gcc runtime in Gnustep's Foundation library, but the modern runtime definitely implements them directly.

Ah, I must've confused objc_retain with NSObject! I remembered having to remove references to NSObject in #32 because it was defined in libobjc on mac but not in gnustep.

I've fixed the spacing and it sounds like everyone agrees that this rust-objc is the right place for this?

Review ping.

@SSheldon ping

Sorry, procrastinated responding because I wasn't sure what to say without more time to think, and last weekend I was out of town. This weekend I've had some time though!

It feels very odd to have autorelease pool functionality without retain/release functionality in the objc crate, so after adding this I'm also going to add retain/release functionality. I think I've gotten some ideas of how I want to do that.

Current problem, though, is how to test any reference counting functionality. The problem is that the reference counting implementations basically require that your object subclass NSObject (like having retain/release/autorelease/dealloc methods). And unfortunately the tests can't currently use NSObject, because it's not available from the GNUstep runtime. So I'm currently investigating if I can get the GNUstep Foundation working.

When that's figured out, we can merge this and write some tests for it.

Okay, after a very long struggle: I've gotten to an okay place with the GNUstep tests and I've added some reference counting utils on master.

Can you rebase this change and:

1. make sure the tests are still passing on Travis
2. move autoreleasepool into the rc module

Done. I added a test of the autorelease functionality as well.

Thank you! Looks great.

What would be even better if autoreleasepool closure could return a value. Otherwise, it doesn't seem to be applicable much to us, i.e. more often then not we want ARP around some object creation that we retain.

@SSheldon how do you feel about yanking the version, fixing autoreleaespool to return a value, and releasing a new patch version? I don't think anybody is using the new function yet.